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Abstract 

Level design is often characterised as “where the rubber hits the road” in 
game development. It is a core area of games design, alongside design of 
game rules and narrative. However, there is a lack of literature dedicated to 
documenting teaching games design, let alone the more specialised topic of 
level design. Furthermore, there is a lack of formal frameworks for best 
practice in level design, as professional game developers often rely on 
intuition and previous experience. As a result, there is little for games design 
teachers to draw on when presented with the opportunity to teach a level 
design unit. In this paper, we discuss the design and implementation of a 
games level design unit in which students use the StarCraft II Galaxy Editor. 
We report on two cycles of an action research project, reflecting upon our 
experiences with respect to student feedback and peer review, and outlining 
our plans for improving the unit in years to come. 
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Introduction 

The use of games within education has been growing for many years (Charlier & De Fraine, 

2012). Games have been shown to be effective vehicles for teaching a variety of subjects, such as 
maths, languages, and science (Razak, Connolly & Hainey, 2012). Games can be used to motivate 
computer science students to learn programming skills (Angotti, Hillyard, Panitz, Sung & Marino, 
2010; Eagle & Barnes, 2009). Students can also gain valuable skills from learning to design 
games, such as problem solving, reasoning, and creative thinking (Cheng, 2009). However, as a 
degree in itself, games development is relatively new to higher education. As a result, there is little 
published on methods and approaches for teaching games design in higher education. The question 
therefore arises: how do we teach students to be effective game designers? 

First, we should establish why it is important to teach students to design games. Apart from the 
growing importance of games in education, video games are becoming increasingly pervasive and 
influential in our society. The global video games market is expected to grow from US$52.5 
Billion in 2009 to US$86.8 Billion in 2014 (Haukka & Chorazy, 2011). However, the implications 
are not just financial. The majority of people are playing games regularly, with 92% of Australian 
households having a device that is used to play games and 57% of game players playing daily or 
every other day (Brand, 2012). The “typical” game player has also evolved over the last few years, 
with games reaching far and wide into society. The average Australian game player is now 32 
years old, 43% of Australians aged 51 or over play games, and 47% of game players are female 
(Brand, 2012). Consequently, the design of video games is now playing an influential role in our 
everyday lives. 

The majority of published work on teaching games development focuses on capstone projects 
(Bidarra, Boers, Dobbe & Huijser, 2008; Linhoff & Settle, 2009; Schaefer & Warren, 2004) or 
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developing team skills (Brown, Lee & Alejandre, 2009; Maxim, 2006; Settle, Linhoff & 
Berthiaume, 2008). There is a lack of papers focused on teaching games design, let alone the more 
specialised area of games level design. Level design is often referred to in games development as 
“where the rubber hits the road.” It is where the player is confronted with the rules and content of 
the game. It is also an area in which there is a lack of formal frameworks for best practice, with 
professional game developers drawing largely on intuition and previous experience (Hullet & 
Whitehead, 2010). Consequently, when presented with the opportunity to teach a unit on games 
level design, there is little in the way of industry frameworks or previous academic materials to 
draw upon. In this paper, we discuss the design and implementation of a unit on games level 
design. We report on two cycles of an action research project (Norton, 2009) to critique and 
improve the unit, reflecting on our experiences with reference to student feedback and peer review. 
The first cycle was conducted in 2011 and the second in 2012. 

Games Level Design 

The Queensland University of Technology (QUT) offers a three-year Bachelor of Games and 
Interactive Entertainment (BGIE) degree. In the BGIE, there are three majors: game design, 
animation, and software technologies. The Games Level Design unit is available to students who 
have completed the first and second year games design units. As a result, the majority of students 
enrolled in Games Level Design are third year students of the games design major. The Games 
Level Design unit was first offered in 2011 and was subsequently offered in 2012. In both years, 
the class size was approximately 60 students. 

Level Design 

Before we detail the design of the unit, it is first necessary to clarify what we mean by levels and 
what is entailed in the design of levels. The definition of levels is quite broad and varies 
significantly depending on the type of game. In general, levels are distinct areas in a game, which 
can be separated by geography, narrative, or gameplay (Rouse, 2004). In narrative-driven games, 
levels are like chapters in a book, with each level having tension and release moments that create 
an emotional curve. From a gameplay perspective, the separation and order of levels has a 
substantial impact on the flow of the game, as players often play one level per play session and 
feel a sense of accomplishment after completing each level. 

The role of the games level designer is varied and complex. The overall goal of a level is to 
provide an engaging gameplay experience (Rouse, 2004). However, what this means and how this 
is achieved varies significantly from game to game. Creating a level involves constructing the map 
or physical layout of the level; designing and implementing the narrative and objectives; placing 
objects, enemies, and characters; scripting events and character/enemy behaviour; integrating 
aesthetics (e.g., sounds, music, lighting); and providing opportunities for exploration, problem 
solving, and other gameplay. In the production of a game, all this must be done amidst incomplete 
game design and implementation, changing requirements, buggy tools, shifting deadlines, and 
budget cuts. 

Teaching Approach 

Developing game levels is a very hands-on, practical activity, which can be thought of as “applied 
games design”. Accordingly, teaching games level design necessitates a practical approach. Our 
practical approach to teaching games level design was underpinned by interactive, participatory 
lectures; hands-on practical sessions using StarCraft II in the games laboratory; and project-based 
assessment that resulted in a complete, playable, and engaging game level. 
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Lectures 

The content of the unit was taught in seven two-hour lectures (see Table 1). We also offered an 
additional two lectures that covered potential pathways for the students upon graduating: getting a 
job, independent game development, and games research. Due to the lecturer having substantial 
games industry experience, the lectures included numerous industry examples. The students were 
also encouraged to volunteer examples from their own game playing experiences, which 
contributed significantly to shaping the classes. The material covered in lectures included all facets 
of games level design, including gameplay, environments, storytelling, pacing, training, artificial 
intelligence (AI), and getting feedback on levels via playtesting. 


Table 1\ 

Games Level Design lectures 

Lecture 

Content 

1. Introduction 

Introduction to the unit and games level design. 

Basics of level design, good level design, and the 
level design process. 

2. Level Gameplay 

Gameplay, formal elements, world building, rules, 
content, interactive worlds, and puzzles. 

3. Level Environments 

Camera; visual information, design, style, and 
theme; and game audio. 

4. Storytelling In Levels 

Premise, characters, story, conflict, dramatic arc, 
storytelling contexts, the player’s story, level story 
outline, narrative elements, and emergent narrative. 

5. Level Pacing & Training 

Play; training areas, approaches, and methods; 
challenge, difficulty, dynamic difficulty adjustment; 
pacing; and difficulty versus pacing. 

6. Level Artificial Intelligence (AI) 

Game AI basics, goals of game AI, and AI by game 
genre. AI in game levels: goals, motivations, key 
concepts, scripted events, and emergent 
characters. 

1. User Testing Levels 

Playtesting: testers, script, methods, and phases. 

User testing case studies and user testing plan. 


Practical sessions 

Twelve two-hour practical sessions were available to students (see Table 2). During practical 
classes, students engaged in hands-on tutorials using the StarCraft II Galaxy Editor, worked in 
groups on their levels, or participated in assessment items. The first two practical classes were 
dedicated to the students familiarising themselves with StarCraft II, as well as getting a feel for the 
types of levels that could be created using the editor. The next three classes introduced the students 
to using the editor by completing focused tutorials, deconstructing existing levels, and beginning 
prototyping of their own designs. The remainder of the practical classes allowed the students to 
meet in their groups and work on their levels with tutor support. 
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Table 2: 

Games Level Design practical classes 

Practical 

Exercise 

1: Play StarCraft II 

Play and analyse StarCraft II campaign and/or 
custom maps. 

2. Play StarCraft II 

Play and analyse StarCraft II community levels. 

3. StarCraft II editor tutorials 

Complete tutorials for using the StarCraft II Galaxy 
Editor. 

4. Reverse engineering 

Work in groups to reverse engineer existing 

StarCraft II levels. 

5. Prototype proposals 

Prototype student proposal concepts in the 

StarCraft II Galaxy Editor. 

6. Design document 

Work on design document and/or levels in groups. 

7. Playtesting 

Design and implement a level playtesting script. 

8-9. Level construction 

Work on levels in groups. 

10. Presentations 

Group presentations for assessment 2A. 

11. Level construction 

Work on levels in groups. 

12. Peer assessment 

Play final levels and carry out peer assessment. 


Assessment 

The assessment for the unit was comprised of five items (see Table 3), distributed throughout the 
semester, and culminating in the completion of a final, playable, level. Each piece of assessment 
was designed to step the students through the process necessary to help them arrive at their final 
product. The students worked in groups to develop their final level, which received a group mark. 
However, the majority of their work was assessed on an individual basis. The first two assessment 
items were entirely individual efforts. The first item (Al) involved the analysis of three 
community-created StarCraft II levels and the second item (A2) required each student to propose 
two levels that could be constructed for the group project. 

Students were subsequently organised into groups of four, for which students could: a) choose 
their own groups, or b) request to be assigned to a group. Once in their groups, students needed to 
review the eight individual level proposals (from A2) and decide on a proposal to construct as their 
final level. Students were able to choose one of the eight proposals, a combined/modified 
proposal, or a new proposal. The students were required to adopt specific roles in the group (see 
Table 4), in order to try and manage the complexities that are often entailed with group assessment 
(Settle, Linhoff & Berthiaume, 2008), as well as to more closely emulate a professional games 
design team. The purpose of the group roles was for each student to take the lead on their 
designated areas of the level design. However, it was still left to the students to ensure equitable 
division of workload, as the amount of work involved in each of these roles would vary depending 
on the individual level being developed. Each student was required to write a section of the level 
design document (A3) and to present a portion of the progress presentation (A4), corresponding to 
his or her assigned group role. 
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Table 3: Games Level Design assessment 


Assessment Item 

Mode 

Weight 

Content 

A1 

Level Design 
Analysis 

Individual 

15% 

Analyse three StarCraft II community 
levels, with respect to game design 
elements and innovation. 

A2 

Level Design 
Proposal 

Individual 

15% 

Propose two potential levels to develop 
in the group project. 

A3 

Level Design 
Document 

Group, 

assessed 

individually 

20% 

Full design document for the selected 
level to be constructed in groups. 

A4 

Progress 

Presentation 

Group, 

assessed 

individually 

20% 

Reflective presentation on progress on 
the group levels. 

A5 

Final Level 

Group, peer 
assessed 

30% 

Submission of the final levels, assessed 
via peer playtesting and evaluation. 


The final level (A5) was the only assessment item for which the students were assigned a group 
mark. In the final practical session of the semester, each student was required to play and grade 
two other levels. As a result, eight students graded each level. In order to grade a level, students 
played the level for up to 45 minutes and marked the level against a criteria sheet. The criteria 
sheet included criteria for narrative; goals and objectives; environment; gameplay; pacing and 
training; and innovation. In order to award the final mark for each level, the unit coordinator 
reviewed all the grades and feedback provided by the students and determined a moderated grade. 


Table 4\ Group roles 

Role 

Responsibilities 

Narrative & Goals 

Map & Level Flow 

Gameplay & Innovation 

Playtesting & Training 

Story, characters, goals, and objectives. 

Layout, progression, and placement of objects/AI. 

Gameplay elements, scripting, and innovation. 

User testing plan, training, pacing, and difficulty. 


StarCraft II Galaxy Editor 

The assessment and practicals for the Games Level Design unit are based in the StarCraft II 
Galaxy Editor (see Figure 1). StarCraft II is a real-time strategy game, developed by Blizzard and 
released in 2010. The StarCraft II Galaxy Editor was selected as the development tool for this unit 
to enable the students to focus on level design. StarCraft II is a complete and highly polished 
product that includes an editor that is designed for end users, as opposed to game developers. 
There is a large community dedicated to making custom maps and campaigns for StarCraft II and, 
as a result, there is a wealth of examples, tutorials, and resources available to the students. 
Simultaneously, the Galaxy Editor is also a very flexible and powerful tool. The students are not 
limited to only creating real-time strategy game maps. Rather, they are able to extensively modify 
most aspects of the game, through terrain building, object editing, and scripting, to create a very 
diverse set of game experiences. Blizzard also generously provided each of our students with an 
educational license to use StarCraft II for free for the semester. 
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Figure 1: StarCraft II Galaxy Editor 


Student Projects 

In 2011, there were 14 final student projects in total, which included arcade, role-playing, racing, 
action, strategy, and simulation games. The students were instructed to create an innovative game 
level and to avoid developing a level that would fit comfortably within the existing StarCraft II 
campaign. Groups were to look at the tools and resources at hand and create an innovative and 
creative product. Each and every group demonstrated that they were capable of meeting this 
challenge. 

In 2011, we were fortunate to have four of our student projects covered in a prominent Australian 
PC gaming magazine, PC Powerplay (Hull, 2011). The four games covered by the magazine were 
Silk Road, Eternal Templar, Space Cannonball Run II, and Starvest (see Figure 2). Silk Road is a 
space trading simulation game, Eternal Templar is a board-game inspired strategy game, Space 
Cannonball Run II is a combat racing game, and Starvest is an action role-playing game. The 
variation in these levels demonstrates the innovation displayed by the students, as well as the 
versatility and flexibility of the StarCraft II Galaxy Editor. 
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Figure 2: Starvest, an example level created by students using the StarCraft II editor 


Student Feedback 

In 2011, the students were asked to provide feedback on the unit twice during the semester. The 
first round of student feedback was collected midway through the semester, via an in-class online 
survey. The second round of student feedback was collected at the end of the semester, via the 
university’s formal feedback mechanism, which is also administered via online survey. 

Mid-Semester Feedback 

During practical classes in week seven (out of 13) of semester, students were asked to participate 
in the mid-semester survey. The students were asked to respond to three questions: 

What have been the best learning experiences in games level design so far? 

Is there anything that you felt was missing or that you would like more 
time/support/information for? 

What would you recommend changing or adding to improve the unit in future? 

Best Learning Experiences 

There were 23 responses to the question relating to the students’ best learning experiences so far in 
the unit. The responses most frequently related to the lectures (N=8), as well as to the practicals 
and use of the StarCraft II editor (N=8). Students responded that the lectures were interesting, well 
structured, useful, informative, involved open discussion, and that plenty of industry examples 
were provided. Students appreciated the hands-on practical classes and learning to use the 
StarCraft II editor. Students also enjoyed learning about level design in general (N=5), and found 
the assessment to be practical and well structured (N=2). 
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Lacking Support or Information 

There were 20 responses to the question relating to areas where the students felt they required 
additional support or information. The students’ responses most frequently related to the practical 
classes (AM 0), followed by the lectures (N=7), and the assessment (N= 3). Students’ concerns with 
the practical classes related to wanting more direct instruction and technical support for using the 
StarCraft II editor and a clearer link between the lecture content and practical class exercises. For 
the lectures, the students wanted additional examples of good and bad level design, as well as 
audio recordings of the lectures to be made available. Finally, the students felt that they were 
spending too much time on written pieces of assessment and would have preferred to dedicate this 
time to working on their levels. 

Future Improvements 

There were 25 responses to the question relating to suggested future improvements and changes to 
the unit. The students’ responses most frequently related to the assessment (N= 8) and lectures 
(N=8), followed by the use of StarCraft II (N= 4) and the practical classes (N=5). In regards to the 
assessment, students suggested having fewer assessment items each with a higher weighting, with 
a particular view to removing some of the written assessment. For the lectures, students suggested 
more level-design specific content and less general game design content, as well as more examples 
and more use of videos. For the practical classes, students suggested more direct instruction, more 
technical support in using the editor, and more structured classes. Some students felt that they 
would have preferred to use a different tool to create their levels, rather than the StarCraft II editor. 
Although, it was suggested that any replacement tool would need to be as easy to use, include as 
many prebuilt assets, and have the same flexibility as StarCraft II. 

End of Semester Feedback 

At the end of each semester, QUT collects formal feedback from students on their units, courses, 
and teachers. For Games Level Design, students were asked to respond to two questions: 

What were the best aspects of this unit and why? 

What aspects of the unit are most in need of improvement and why? 

Best Aspects of the Unit 

There were 18 responses to the question relating to the best aspects of the unit. The students’ 
responses most frequently related to the lectures (N= 6) and the use of StarCraft II (N=6), followed 
by the unit overall (A=4) and the assessment (N= 2). Students found the lectures to be informative, 
relevant, enjoyable, and grounded in industry practice. The students responded that using the 
StarCraft II editor simplified creating levels and allowed rapid development of prototypes and 
gameplay. They reported using a modern game as learning material to be “refreshing”, appreciated 
being exposed to new technologies, and found it to be challenging but rewarding. The students 
reported that the unit overall was fun, relevant to their future careers, had a reasonable workload, 
and assisted them in understanding the fundamentals of good game design. 

Aspects for Improvement 

There were 22 responses to the question relating to aspects of the unit that needed improvement. 
The students’ responses most frequently related to the assessment (N= 9) and the practical classes 
(N= 7), followed by the use of the StarCraft II editor (/V=3) and the unit overall (/V=3). Students 
reported that there was too much assessment overall and too much written, theoretical assessment 
in particular. They suggested that the first two assessment items be reduced or removed, which 
would allow more time to be dedicated to developing their levels. Students responded that the 
practical classes felt detached from the lecture material. They also would have liked more 
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technical support from tutors in practical classes and did not like that they had to teach themselves 
how to use the editor for the most part. Some students did not like being forced to use the StarCraft 
II editor and suggested using Epic’s UDK or Valve’s Source engine instead, or allowing students 
to choose which tool they would use. Finally, some students felt that the unit was too focused on 
what they considered general games design, as opposed to level design. These students had 
expected the unit to be more about level architecture or construction (i.e., the physical mapping of 
the levels), rather than all aspects of level design. 

Peer Review 

In 2012, the Games Level Design unit was lectured and coordinated by a different academic, as the 
author was on maternity leave. As a result, we had the unique opportunity to gain feedback and 
input from a fellow lecturer, also with substantial games industry experience. Before handing over 
the unit, both lecturers met and discussed the 2011 implementation of the unit and made a plan for 
revisions in 2012. Likewise, at the end of 2012, both lecturers met again and discussed the 2012 
implementation of the unit and the outcomes of the changes made to the unit. In addition, at the 
end of 2012, the author met with a graduate student who had completed the unit in 2011 and then 
went on to tutor the unit in 2012, to gain feedback on the design and implementation of the unit. 
Unfortunately, there was no feedback collected from students in 2012, due to the university 
revising their student feedback collection mechanism and the author being on maternity leave. In 
this section, we discuss the changes made to the unit in 2012 and the feedback from the review 
sessions held with both the 2012 lecturer and tutor. 

Lecturer’s Reflections 

Following the completion of the 2011 iteration of the unit, the outgoing lecturer reflected on her 
experiences with the unit, in light of the student feedback, and made several recommendations for 
revisions to the unit for the incoming lecturer for 2012. The key recommendations were to: 

Remove assessment item Al, keeping it only as an in-class practical exercise. The reason 
for this recommendation was that the students seemed to struggle with the amount of 
assessment, particularly written assessment, and, that, although this constituted an 
important practical exercise, it wasn’t crucial to assess this item. 

Reduce assessment item A2 to require the students to propose only one level to develop, 
rather than two. Reasoning for this recommendation again included reducing the amount 
of written assessment. However, it also seemed more useful to allow the students to 
concentrate on developing one solid proposal, rather than dividing their attention between 
two, potentially less polished, ideas. 

Separate out the professional design document from the academic theoretical justification. 
After marking the students’ proposals and design documents, it was apparent that 
requiring the students to incorporate theoretical justification into their design documents 
resulted in documents that did not resemble industry documents. However, as 
understanding and articulating the theory behind their decisions was central to the unit, it 
was still necessary for this material to be assessed. Consequently, it was recommended 
that students should be required to separate out these two components of their assessment. 

Replace assessment item A4 with a practical class participation mark. The progress 
presentation did not meet the goals of providing the students with an opportunity for 
reflection and to review their progress. The students required more immediate feedback 
on their progress, as well as more encouragement to meet their team members on a 
regular basis. Consequently, a participation mark was suggested to encourage students to 
attend and participate in practical classes, including engaging with their team. 


2013 Vol. 6 No. 2 


20 



Journal of Learning Design 


Sweetser 


2012 Implementation 

The major changes implemented in 2012 were to the assessment for the unit. In response to 
student feedback and the lecturer’s reflections, a few key changes were made. Assessment A1 (see 
Table 3) was removed and kept only as a practical class exercise. Also, assessment A2 was 
modified so that students only needed to propose one level concept, rather than two. Assessment 
A4 was also removed, as students had required earlier, ongoing, and more immediate feedback on 
their progress. In place of assessment items A1 and A4, a participation mark for the practical 
classes was introduced instead. Students could gain a maximum of 35% of their grade for the unit 
by participating in practical classes, which included completing set exercises, participating in 
discussions, and working effectively with their teams on their projects. Another key change to the 
assessment was that students were required to clearly separate out the theoretical justifications in 
their proposals and design documents by using text boxes. In this way, the design could be kept 
clean and emulate a professional document, but still include the necessary theoretical 
underpinnings required to demonstrate academic merit. 

Peer Review Sessions 

Two peer review sessions were conducted, one with the 2012 lecturer and one with the 2012 tutor. 
Both review sessions took the format of informal, open discussions. The reviewers were first asked 
for any general feedback on the unit, which was then followed by questions relating specifically to 
assessment, lectures, practical classes, and the use of StarCraft II. Both reviewers reported that the 
unit went well and that informal feedback from the students was positive. 

Peer Review One 

The majority of the feedback from the 2012 lecturer related to the assessment. He found that the 
overall workload of the unit was more reasonable, with the removal of the two assessment items 
and the addition of the participation mark. He reported that the participation mark was effective in 
getting the students to attend and engage in the practical classes. He found that the roles for the 
project and design document worked well and resulted in an equitable workload division between 
the team members. However, he suggested that, in future, students could submit their individual 
components of the design document separately (rather than as a single group document), to ensure 
that each student was accountable for timely submission of their own work. He also suggested that 
participation marks could be collected via an online system (e.g., with an iPad in class), rather than 
marking with paper and pen in each class. Similarly, the students could directly enter their peer 
review marks for the final level marking session into an online system, to avoid the substantial 
amount of work in entering and collating student marks. Finally, he suggested that it would be 
worthwhile identifying team issues earlier on and having a contingency plan of what to do with 
students that aren’t contributing to their team projects, such as taking on a smaller, individual 
project. 

In regards to the use of StarCraft II, the lecturer reported that he felt that it worked well as the tool 
for the unit. He identified that the students that kept within the bounds of what the editor was 
designed for (i.e., top-down or third-person strategy, role-playing, or action games), were able to 
develop the most polished levels. He found that the students could face difficulties if they tried to 
stray too far from the core gameplay of the editor, particularly if they had little programming 
experience. He cited that a couple of the teams had made real-time strategy games, but that they 
had been able to do so without making StarCraft II clones. They simply kept away from the core 
mining, construction, and production mechanics of StarCraft II. 

Peer Review Two 

The feedback received from the 2012 tutor had more of a focus on the practical classes, the team 
projects, and the StarCraft II editor. The tutor identified that due to constant updates made to the 
StarCraft II editor, the editor walkthroughs used in the practical classes became quickly out of 
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date, with some not working at all. She reported that some of the students were reluctant to get 
their hands dirty with the editor, particularly students who lacked programming skills, so she had 
made it a point to show them something new with the editor each week. She suggested that, in 
future, a key component of the editor (e.g., pathing, triggers) could be demonstrated to the students 
at the start of each practical class. 

The tutor reported that the assessment provided a good workload for the students. She identified 
that, in general, the students had trouble with the theory in the assignments and that both written 
assignments had lacked theoretical justifications from the students. In regards to the projects, she 
reported that some students spent a lot of time on the aesthetics of their levels, rather than on the 
functionality. These students had been reluctant to fine-tune, balance, and polish their levels in 
response to playtesting feedback, despite having achieved functional levels early in the semester. 
She also identified that many students had issues with scope for their levels, trying to achieve too 
much in the small amount of time available to complete their levels. Finally, she found that 
students tried to stick too closely to their assigned group roles, which resulted in uneven 
distribution of work. 

In regards to StarCraft II, the tutor reported that she thought it was a good choice for the unit. She 
identified that the editor is simple, has everything that the students need, and its limitations impose 
useful restrictions on the student projects. At the outset of the unit, the students were able to play 
the levels created by the 2011 students, which allowed them to get a feel for what the editor is 
capable of and what they can hope to achieve in a semester of development. She reported that the 
levels created by the 2012 students were innovative, despite the requirement for innovation being 
relaxed from the previous year. Only two teams made real-time strategy game levels, which were 
different to StarCraft II levels due to rich narratives created by the students. 


Reflections and Future Revisions 

Based on student feedback in 2011, it seems that the Games Level Design unit made a good 
addition to the BGIE degree, in terms of further developing the students’ practical game design 
skills and building on their knowledge of game design theory. However, in its first iteration in 
2011, the unit had a number of issues that needed some attention, in order to ensure students were 
getting the most out of their experience in the unit. The key areas that were identified as needing 
improvement in 2011 were the assessment and the practical classes. The changes made in 2012 
made some progress towards addressing the issues identified by students in these areas. In this 
section, we reflect on the student feedback, changes to date, and peer reviews of the unit to 
identify opportunities for future improvement to the unit. In addition, it is necessary to review the 
choice of StarCraft II as the development tool for the unit and decide whether to continue with it in 
future years or to explore other options. 


Assessment 

In 2011, student feedback and lecturer reflections indicated that there was too much assessment for 
the unit, particularly written assessment. In response to this feedback in 2012, we removed the first 
written assessment item, reduced the size of the second written assessment item, and removed the 
progress presentation. In lieu of these assessment items, we added a practical class participation 
mark to encourage students to attend practical classes and engage with both the practical exercises 
and their project teams. Peer review suggested that these changes resulted in a more manageable 
workload for the students and that engagement in the practical classes was improved. 

The peer review sessions identified a few outstanding issues that still need attention for the next 
iteration of the unit. Potential future improvements to the unit include: 
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Requiring each team member to submit their component of the team design document; 

Collecting practical class participation marks and final level peer reviews electronically; 

Using participation marks to help identify team issues earlier in the semester and 
responding quickly to support students in managing these issues; 

Clarifying the importance of clearly communicating theoretical justifications for written 
assignments; 

Ensuring students leave adequate time for responding to playtesting feedback and that 
they understand the importance of polishing, balancing, and fine-tuning their levels; 

Guiding teams in determining a realistic scope for their levels and supporting teams in 
equitable division of workload. 


Practical sessions 

In 2011, students reported that the practical classes felt detached from the lecture material and that 
they wanted more direct instruction and technical support for using the StarCraft II editor. No 
formal changes were made to the practical classes in 2012. However, a notable improvement came 
from having a tutor who had completed the unit the year before and who could provide extensive 
technical support to the students in using the StarCraft II editor. 

Based on student feedback and lecturer reflections from 2011 and the peer reviews from 2012, 
potential future improvements to the practical classes include: 

Review the practical classes to improve alignment with lecture material. 

Update practical class exercises to reflect the current (and changing) state of the StarCraft 
II editor. 

Include a short instructional session and practical exercises using the StarCraft II editor in 
each practical class. 


StarCraft II 

In 2011, feedback indicated that student opinion was divided on the use of the StarCraft II editor 
for the unit. Some students found StarCraft II to be simple, powerful, and exactly what they 
needed to create their levels. Conversely, other students indicated that they would have preferred 
to use another editor (e.g., Epic’s UDK or Valve’s Source engine) or have been allowed to choose 
their own editor. This feedback raised the question of whether another tool should be selected for 
the unit or whether students should be permitted to choose their own tool. 

The peer review feedback following the 2012 iteration of the unit supported the continued use of 
StarCraft II as the tool for the unit. The teaching staff reported that it was simple, had everything 
the students required, and also limited what they were able to do, which helped in constraining 
their projects. In addition, the accumulation of levels created by previous teams of students in 
2011, and now 2012, further supports future students by providing examples and benchmarks of 
what can be achieved in the unit. The peer reviews also confirmed the author’s hesitations in 
allowing students to select their own development tool, in that limited technical support could be 
provided to the students across multiple tools. The issues with using the other suggested tools were 


2013 Vol. 6 No. 2 


23 



Journal of Learning Design 


Sweetser 


also confirmed by the peer reviews, which were that the students would be overly focused on level 
architecture, rather than level design as a whole. Consequently, the continued use of StarCraft II 
for the unit seems to be the best choice at this stage. 

Conclusions 

The goals of this paper were to discuss the design and implementation of a games level design 
unit, along with our reflections on the first two iterations of the unit, and plans for future 
improvements. Thoughts and experiences of designing and running a games level design unit have 
been shared in the hope that this approach and lessons learned will inform other educators in the 
same endeavour. In addition to the detailed analysis of this unit, reflections on some important 
general issues have been provided, including achieving the difficult balance between academic 
theory and industry practice; providing students with sufficient scaffolding for learning while not 
over-assessing; the benefits of using contemporary industry examples and tools; designing for fair 
group assessment and supporting teams in game development projects; and the importance of 
providing technical support to students for complex tools. Through this paper, some progress has 
been made in providing guidance to educators in developing games design units and also in 
answering the broader question of how students can be encouraged to be effective game designers. 
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